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PREFACE 


This document describes the GNC architecture design and associated interfaces required for all 
ARES simulations. Questions about this document should be addressed to Robert Gay 
(robert.gay-l@nasa.gov, 281-483-6330). 
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1.0 INTRODUCTION 


The purpose of this document is to describe the GNC architecture and associated interfaces for 
all ARES simulations. Establishing a common architecture facilitates development across the 
ARES simulations and provides an efficient mechanism for creating an end-to-end simulation 
capability. In general, the GNC architecture is the frame work in which all GNC development 
takes place, including sensor and effector models. All GNC software applications have a 
standard location within the architecture making integration easier and, thus more efficient. 

2.0 GENERAL REQUIREMENTS 

2.1 GNC architecture shall handle all flight phases. 

2.2 GNC architecture shall be modular and scalable. 

2.3 GNC architecture shall support the capability to bring together 
independently developed “major” flight phases, such as ascent, orbit, entry, 
etc., in an end-to-end simulation. 

2.4 GNC architecture shall allow for running multiple modules (sensors, 
navigation, guidance, control/jet selection, and effectors) simultaneously, 
while closing the loop on a single string. 

2.4.1 GNC architecture shall allow for single-string versions of the simulation. 

3.0 GNC ARCHITECTURE DESCRIPTION 

3.1 S_define-Level Model Flow Diagrams 

The following flow diagrams shown in 

Figure 1, demonstrate the GNC architecture by illustrating the function calls and data flow at the 
Sdefine level for the trick-based ARES simulations. The naming convention shown in the 
diagrams should be followed in all ARES simulation development; however, descriptors may be 
used for each type of manager function such as “cev_high_rate_pseudo_nav_mngr” etc. 
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3.1.1 SIM xyx (single rate group) Flow Diagram 


Figure 1 shows the GNC architecture for all ARES simulations with a single (FIIGH) rate group. 


S define 
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pass sim_config struct 


cev_high_rate_gnc 

executive 


1 


cev veh executive 
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mode transition 



ce v_hi gh_r a te_nav_mngr 1 

(calls nav and upp functions) 


ce v_h i gh_r a te_nav_mngrN 

(calls nav and upp functions) 
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FHW model 
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e f f e c to r_typeA_l 


e f f e c t o r_ type A_N 


Trick 


GNC Sim 
Config 


pass sim_config struct 

_ . 


FHW model 


collect effector forces /torques 


FSW 


Figure 1: SIM xyz GNC Architecture Flow Diagram (single rate group) 
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3.2 GNC Simulation Configuration 

In order to allow for multiple versions of sensors, navigation, guidance, control, and effectors to 
be active simultaneously, while closing-the-loop on a single string, a non-flight software 
simulation configuration data structure is necessary. This structure is used to take all applicable 
outputs and pass (via a pointer) only the desired data down the GNC chain: sensors - navigation 
- guidance - control - effectors. GNC state and status information is also passed with 
sim config parameters back to the vehicle executive for mode transitions. Since pointers are 
used, the memory addresses only need to be assigned once at initialization. Fortunately, trick 
allows this to be done with input data using standard “C” syntax. Figure 2 contains an example 
of the GNC simulation configuration data structure. 


typedef struct! 







cev gnc quid ss T 

* 

guid ss; 

/* 

— 

Guidance state and status 

*/ 

cev gnc nav ss T 

* 

nav ss; 

/* 

— 

Nav state and status 

*/ 

cev gnc cntrl ss T 

* 

cntrl ss; 

/* 

— 

Control state and status 

*/ 

pose out T 

* 

LDO; 

/* 

-- 

LIDAR sensor output 

*/ 

pose out T 

* 

NFO; 

/* 

-- 

NFIR output 

*/ 

imu out T 

* 

IMUO; 

/* 

-- 

IMU output 

*/ 

gps out T 

* 

GPSO; 

/* 

-- 

GPS output 

*/ 

str out T 

* 

STRO; 

/* 

-- 

Star trckr out 

*/ 

general nav T 

* 

NAV; 

/* 

— 

General nav struct 

*/ 

general guid out T 

* 

GO; 

/* 

-- 

General guid output struct 

*/ 

CONTRL PARAM 

* 

CTRL; 

/* 

-- 

General control struct 

*/ 

double 

ef f 

force [3 ] ; 

/* 

N 

effector force 

*/ 

double 

ef f 

torque [ 3 ] ; 

/* 

NM 

effector torque 

*/ 

} veh gnc sim config 

T; 














Figure 2: GNC Simulation Configuration Data Structure Example 

3.3 Rate Groups 

Sensor models, effector models, and the Onboard Trajectory Manager (OTM) run at whatever 
frequency is desired for the given function, where as the Vehicle Executive, GNC Executive (or 
pseudo GNC executives), and the Manager functions are divided into appropriate rate groups: 
LOW, MEDIUM, and HIGH for example. The Vehicle Executive is always called at the 
“HIGH” rate. The GNC executive (or pseudo GNC executives) and the Manager function names 
are prefixed with “low_rate”, “med_rate”, or “high_rate” descriptors to designate their 
frequency. Clearly, all the functions executed within a Manager are called at the same rate, 
unless additional logic is added to slow down a given function call. 
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3.4 Sensor Models 

The purpose of sensor models is to emulate the functionality of sensor flight hardware. Each 
model will be called at the Sdefine level near the top of the vehicle simobject (see 


Figure 1). 

3.5 Phase, Segment, Mode, Sub-modes, and Tasks 

Phase: Major flight regime: Ascent, Orbit, Entry, Transit, ... 

Segment: Logical division of a Phase: Far-Field Rendezvous, Near-Field Rendezvous, Prox-ops, 
Final Approach. . .(Orbit Phase) 

Mode: Definition of general GNC capability: absolute navigation, relative navigation, ascent 
guidance, Lambert targeting, entry guidance, entry control, ascent control, etc. Each mode is 
defined by a combination of six types of sub-modes. 

Sub-mode: Low-level definition of GNC capability. There are six types of sub-modes: 
translational and rotational Guidance, Navigation, and Control. Logic in the GNC Manager 
functions will make decisions based on the current sub-mode. 

Task: Series of actions necessary to complete a Segment. Each task is an instantiation of a 
Mode, usually involving task-specific data. 

Utilizing the Phase, Segment, Mode, and Sub-mode concept, allows the simulation scenario to be 
largely data driven. Nominal and contingent sequencing can all be predefined if desired and 
driven by time, events, OTM, crew, ground, etc. See /vobs/cev/sims/xyz_sim/- 
Modified_data/task_list/*.d, for examples of this type of data. 

3.6 Vehicle Executive 

The primary purpose of the Vehicle Executive flight software function is to update the Phase, 
Segment, and Mode if the current Task is complete or an override command is given. Task- 
specific data is also updated in this function. Furthermore, the Vehicle Executive contains all 
Mode-transition logic and increments and resets a task-timer, and maintains “previous” Phase, 
Segment, Mode, and Task parameters. Appendix A contains a list of the commands used to 
manipulate nominal and contingency sequencing within the Vehicle Executive. 

The executive data defines the overall mission scenario. This data also defines the Mode via the 
associated Sub-modes. The definition of these Sub-modes are determined through code in the 
Manger functions and task-specific data. Sdefine file location: Called after the OTM functions 
in the vehicle sim_object (see 


Figure 1). 
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3.7 GNC Executive (Pseudo GNC Executives) 

Currently, the “FSW” or prototype FSW GNC Executive is NOT implemented in ARES. The 
purpose of this function will not be fully defined in this document. The iGNC Mode Team will 
produce a fonnal document defining the GNC Executive in the near future. 

The Pseudo Pre GNC Executive and the Pseudo Post GNC Executive are used to simulate the 
functionality of the FSW GNC Executive, while maintaining all the capabilities of the GNC 
simulation configuration. Presently, the Pseudo Pre GNC Executive only sets the current Sub- 
mode. In the future, this function may be responsible for reading data from a “common data 
area” to be passed to the appropriate GNC Manager functions. The Pseudo Post GNC Executive 
is, for now, just a place-holder (does nothing) for future development, such as perfonning data 
writes to a “common data area”. 

3.8 Navigation Manager 

The Navigation Manager is flight software responsible for configuring and selecting the desired 
navigation during flight, including sensor input collection and navigation-derived parameter 
outputs. Decisions within the code are made based on Sub-mode and other necessary parameters 
with respect to those Sub-modes. Figure 3 contains example pseudo-code for a Navigation 
Manager. S define file location: Called after the GNC Executive (or pseudo pre GNC 
executive) in the vehicle sim_object (see 


Figure 1). 
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/* Switch on trans nav sub-mode */ 
switch (VEH->t nav mode) { 

case veh_TN_ORBIT_ABS_ONLY: 

/* Process sensor inputs */ 

nav_input (G, time, LO, NFO, IRCO, IMUO, GPSO, STO, TLMO) ; 

/* Call Hifi nav function */ 
navigated rnp(time, PC->omega, N) ; 
hifi nav (time, NAV, G, HFN) ; 

/* Calculate Chaser States */ 

/* Call inertial nav functions */ 

N->inertial nav = On; 

N->att mat = B TO I; 

N->sensed_accel = INERTIAL^SENSED; 

MtxV (body_rate_chsr , chsr_att->T_body2eci, chsr_att->body_rate) ; 
inrtl nav_params (& (HFN->filter . state .m [ SI->chaser abs x] ) , 

& (HFN->filter . state .m [ SI->chaser abs xd] ) , 

P->accel . cg_sensed_accel_eci_estimate, 
chsr_att->T_body2eci, body_rate_chsr, N) ; 

orb car to elem (N->inertial_pos , N->inertial vel, PC->mu, C_OE) ; 

/* Call planet-relative nav functions */ 

M_TRANS (T_inertial_body_chsr, N->T_body_inertial ) ; 
planet_relative_state ( PRN, N->inertial_pos , N->inertial_vel, 

T inertial body chsr, N->T inrtl_pf ixed, PC->r eq, 
PC->e2, PC->omega) ; 

break; 

} 


Figure 3: Navigation Manager Pseudo-Code 

3.9 Guidance Manager 

The Guidance Manager is flight software responsible for configuring and selecting the desired 
position, velocity, attitude, and attitude rate guidance for all flight phases. Decision making is 
based on Sub-modes, and other necessary parameters with respect to those Sub-modes. Figure 4 
contains example pseudo-code for a Guidance Manager. S define file location: Called after the 
Navigation Manger in the vehicle sim_object (see 


Figure 1). 


Architecture for Exploration 

GNC Architecture Design for ARES Simulation 

Studies (ARES) 

EG-ARES-06-5 

Revision 3.0 

Design Document 

Date: 23 June 2006 

Page 8 of 20 


/* Switch on translational guidance sub-mode */ 
switch (VEH->t_guid mode) { 

case veh TG CW: 

if (task init) 

{ 

TGD->POCW. des met arrival = time + TGD->POCW.dt transfer 

} 

omega = -TN->orb rate lvlh[l]; 

dt transfer = TGD->POCW . des_met_arrival - time; 
if (dt transfer < TGD->POCW . stationkeep dt ) 

{ 

dt transfer = TGD->POCW . stationkeep dt; 

} 

for (i=0; i<3; i++) svi[i+l] = RN->R tcom ccom tlvlh [i]; 

for (i=0; i<3; i++) svi[i+4] = RN->V tcom ccom tlvlh tlvch[i]; 

alt cwtgtng ( TGD->POCW . cwTgtngTypelP, 

TGD->POCW . cwTgtngTypeOOP 
omega, dt_transfer, svi, 

TGD->POCW . des_inplane_pos , 

TGD->POCW . des_ooplane_pos , 
tgtng_sing, dv reqd lvlh ) ; 

MtxV (GO->cmnd delta v, RN->T_cbody tlvlh, dv reqd lvlh); 

break; 

} 


Figure 4: Guidance Manager Pseudo-Code 


3.10 Control Manager 

The Control Manager is flight software responsible for configuring and selecting the desired 
control, command saturation, and jet selection for all flight phases. Decision making is based on 
Sub-modes, and other necessary parameters with respect to those Sub-modes. Figure 5 contains 
example pseudo-code for a Control Manager. S define file location: Called after the Guidance 
Manger in the vehicle sim_object (see 


Figure 1). 
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/* Switch on att/rate control sub-mode */ 

switch (VEH->a cntrl mode) { 

case cev AC RATE DAMP: 
break; 

case cev_AC_ENTRY_SIMPLE_PD: 

/* Turn on Attitude control modules */ 

RCM->Enable res modulator = On; 

PD->Enable simple_pd att con = On; 

/* Rot and trans mode forces firing of couples */ 
SXCM->mode = SIMPLEX_ROT_ONLY; 

/* set RCS config to command module */ 
rcs_config = CMRCS; 

V_COPY (PD->att_gain, ACD->kp) ; 

V_COPY ( PD->rate_gain, ACD->kd) ; 

break; 


Figure 5: Control Manager Pseudo-Code 


3.11 Effector Models 

The purpose of effector models is to emulate the functionality of effector flight hardware. Each 
model will be called at the Sdefine level after the Control Manager in the vehicle simobject 
(see 

Figure 1). 

3.12 Trick Collect Mechanism Utilization 

One of the many advantages of using the trick simulation development environment is the 
Collect Mechanism. The Collect Mechanism is an abstract data collection utility that allows an 
arbitrary number of like data types (not required to be the same type, but it makes things easier) 
to be accumulated at the Sdefine level and then accessed as desired within any function. This 
trick capability has many uses, but the most common ones are collecting forces, torques, and 
gravitational acceleration. In addition, the Orbitalbody code utilizes this mechanism to collect 
all the forces and torques for each body to sum everything for the composite body. 

Dynamic collect statements are typically located after each vehicle sim object. The Orbital body 
collect statements are placed after the “dynamics” sim object. The effector forces and torques to 
be collected will be the ones passed on by the effector model(see 


Figure 1). 
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3.12.1 Transmitted and Non-Transmitted Forces and Torques 

Since the forces and torques for all attached bodies must be accumulated for the composite body, 
the concept of transmitted and non-transmitted forces and torques was created within the 
Orbital body code. If the forces and torques for a given body are to be accumulated for the 
composite body, then they are denoted as “transmitted”. If however the forces and torques are 
only to be applied to the body if it is not attached to anything or if it is the “root” (top-level) 
body, then they are denoted as “non-transmitted”. An example of a transmitted force or torque 
would be one coming from a jet or control surface, while forces from a body-specific aero model 
or torques from a body-specific gravity-gradient model would be non-transmitted. Note, non- 
transmitted forces and torques are imparted on the composite body by computing them with 
respect to the “root” (top-level) body states. Figure 6 contains examples from the ARES ascent 
simulation S define file las sim object. 


/* COLLECT TRANSMITTED EFFECTOR FORCES FOR VEHICLE */ 
collect las . body . orbit . trans . collect_effector_f ore = 

{ 

las . las_prop . thrust [ 0 ] 

} ; 

/* COLLECT TRANSMITTED EFFECTOR TORQUES FOR VEHICLE */ 
collect las . body . orbit . rot . collect_effector_torq = 

{ 

las . las_prop .moment [0] 

} ; 

/* COLLECT DYNAMIC ACCELERATIONS FOR SYSTEM */ 
collect las . body . orbit . trans . collect_dynamic_accel = 

{ 

las . grav . out . accel [ 0 ] , 
las . grav . out . accel_3rd [ 0 ] 

} ; 

/* COLLECT NON-TRANSMITTED TORQUES FOR VEHICLE */ 

/* Aero forces and torques are not transmitted to composite vehicle, 
since a single aero model in the cev cm veh provides composite aero 
when connected, so aero is only used after las sep to model the 
drag on the tower for separation analyses */ 
collect las . body . orbit . rot . collect no xmit torq = 

{ 

las . aero_current .moment b[0] 

} ; 

collect las . body . orbit . trans . collect no_xmit fore = 

{ 

las . aero_current . f orce_b [ 0 ] 

} ; 


Figure 6: Trick Collect Statements Example 
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4.0 INTERFACE REQUIREMENTS 

In order for the GNC architecture to function, all of its components and the lower-level models 
used within it must follow a minimum set of interface requirements. While these requirements 
impose somewhat on model development, the benefits gained through the architecture far 
outweigh the imposition. 

4.1 GNC Simulation Configuration (input data) 

The minimum data set for the GNC simulation configuration structure is all the sensor, 
navigation, guidance, control output data structures and all of the effector model output forces 
and torques. Since the configuration structure has parameters and sub-structures of the same type 
as all the output structures and parameters, the “selected” output can be directed via a pointer 
assigned in the input file. If no selection is desired, this structure is not needed and the outputs 
are fed directly to the appropriate functions. Figure 7 contains an example of GNC simulation 
configuration input data pointer assignments. 

/* Select state and status structures */ 

cev cm_veh.sim_config.guid ss = &cev_cm veh.guid ss; 

/ /cev cm veh.sim config.nav ss = Scev cm veh.hf nav ss; 

cev cm_veh.sim config.nav ss = Scev cm veh.p nav_ss; 

cev cm_veh . sim_conf ig . cntrl_ss = Scev cm veh.cntrl ss; 

/* Select sensor models */ 

//cev veh.sim_config.LDO = Scev veh . lidarl . LDO; 
cev veh . sim_conf ig . LDO = Scev veh . lidarN . LDO; 

//cev veh . sim_conf ig . IMUO = Scev veh . imul . IMUO; 
cev veh . sim_config . IMUO = Scev veh . imuN . IMUO; 

//cev veh . sim_conf ig . GPSO = Scev veh . gpsl . GPSO; 
cev veh . sim_config . GPSO = Scev veh . gpsN . GPSO; 

//cev veh . sim_conf ig . STRO = Scev veh . strl . STRO; 
cev veh . sim_config . STRO = Scev veh . strN . STRO; 

/* Select navigation */ 

//cev veh . sim_conf ig . NAV = Scev veh.p nav; 

//cev veh . sim_conf ig . NAV = Scev veh. pseudo nav; 
cev veh . sim_conf ig . NAV = &cev_veh.hf nav; 

/* Select guidance */ 

//cev veh . sim_conf ig . GO = Scev veh.guid outl; 
cev veh . sim_conf ig . GO = Scev veh . guid_outN; 

/* Select control */ 

//cev veh . sim_config . CTRL = Scev veh.cntrl outl; 
cev veh . sim_config . CTRL = Scev veh.cntrl outN; 

/* select effector models */ 

//cev veh.sim config.eff force = Scev veh . peff . force [ 0 ] ; 

//cev veh . sim_conf ig . ef f torque = Scev veh . peff . torque [ 0 ] ; 
cev veh . sim_conf ig . ef f force = Scev veh . res . force [ 0 ] ; 
cev veh . sim_conf ig . ef f torque = Scev veh . res . torque [0] ; 


Figure 7: GNC Simulation Configuration Input Data Example 
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4.2 Sensor Models (S_define calls) 

The minimum data set required for sensor models is the sensor-related data structure and the 
generic output data structure appropriate for the measurement type. Sensor models will also 
likely have “truth” parameters as inputs for measurement modeling. Furthermore, each sensor 
model structure must have an “enable” flag that will be set via input data and/or have an 
“enable” flag in the calling argument list. Obviously, the sensor model logic must key off of the 
“enable” flag. Note, each type of sensor measurement must have a generic output data structure 
type accessible via the Common Model Library (CML). This output structure must be available 
at the Sdefine level as an input directly to the navigation routines. The minimum contents of 
this output structure are a valid-measurement flag (from the sensor hardware point of view), a 
time tag, and the measurement value. The output structure can either be a sub-structure of the 
sensor structure or instantiated separately in the Sdefine file. Figure 8 contains an example of a 
pose sensor (LIDAR) model interface. 


lidar model ( 







$$$$ 

/* 

Others 

as needed */ 

RELKIN 

* 

RKN, 

/* 

IN: 

True relative states */ 

lidar T 

~k 

LD, 

/* 

INOUT: 

LIDAR data struct */ 

pose out T 

* 

LDO) 

/* 

OUT: 

LIDAR output data struct */ 

or 






lidar model ( 








$$$$ 

/* 

Others 

as needed */ 

RELKIN 

* 

RKN, 

/* 

IN: 

True relative states */ 

lidar T 

* 

LD) 

/* 

INOUT: 

LIDAR data struct */ 

where pose out T 

* LDO 

= & (LD 

->LD0 ) ; 



Figure 8: Sensor Model Interface Examples 


4.3 Vehicle Executive (S_define call) 

The minimum data set for the Vehicle Executive is all rate group frequencies (dt’s), current time, 
general navigation data structure, GNC states and status data structures, and the vehicle 
executive data structure. Figure 9 contains an example of the Vehicle Executive interface. 
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veh veh executive ( 









$$$$ 

/* 

Others if needed */ 


double 

high 

rate dt. 

/* 

IN 

s 

High rate time step 

*/ 

double 

med 

rate dt. 

/* 

IN 

s 

Medium rate time step 

*/ 

double 



time. 

/* 

IN 

s 

Simulation time 

*/ 

general 

nav data T 

★ 

NAV, 

/* 

IN 

— 

General nav data structure 

*/ 

veh gnc 

guid ss T 

* 

SSG, 

/* 

IN 

— 

Guidance state and status 

*/ 

veh gnc 

nav ss T 

* 

SSN, 

/* 

IN 

— 

Nav state and status 

*/ 

veh gnc 

cntrl ss T 

* 

ssc. 

/* 

IN 

— 

Control State and status 

*/ 

veh veh 

executive T 

* 

VEH) 

/* 

INOUT: 

Vehicle Exec data struc 

*/ 


Figure 9: Vehicle Executive Interface Example 


4.4 Pseudo GNC Executive (Sdefine calls) 

The minimum data set for the Pseudo Pre GNC Executive is an enable flag and the vehicle 
executive data structure. The minimum data set for the Pseudo Post GNC Executive is an enable 
flag, the GNC state and status data structures, and the vehicle executive data structure. Figure 10 
contains an example of the Pseudo Executive interfaces. 


veh high rate pseudo pre gnc exec ( 






$$$$ /* 

Others 

if 

needed */ 




Flag enable, /* 

IN: 

- 

Enable flag 



*/ 

veh veh executive T *VEH) /* 

INOUT: 


Vehicle Exec 

data 

struct 

*/ 

veh high rate pseudo post gnc exec ( 






$$$$ /* 

Others 

if 

needed */ 




Flag enable, /* 

IN: 

- 

Enable flag 



*/ 

veh veh executive T *VEH, /* 

INOUT: 

- 

Vehicle Exec 

data 

struct 

*/ 

veh gnc guid ss T * SSG, /* 

IN: 

- 

SC->guid ss 

( sim 

conf ig) 

*/ 

veh gnc nav ss T * SSN, /* 

IN: 

- 

SC->nav ss 

( sim 

conf ig) 

*/ 

veh gnc cntrl ss T * SSC) /* 

IN: 

- 

SC->cntrl ss 

(sim 

conf ig) 

*/ 


Figure 10: Pseudo GNC Executive Interface Examples 


4.5 Navigation 

4.5.1 Manager Function (S define call) 

The minimum data set for the Navigation Manager is an “enable” flag, all the required sensor 
output data structures, the navigation system data structure (truth data for perfect navigation), 
the general navigation data structure, navigation state and status data structure, and the vehicle 
executive data structure. The Navigation Manager may bring in other parameters as needed, but 
that is all that is required for the architecture. The “enable” flag may be set via a local parameter 
declared in the S define file (set in the input file). The sensor output structures are needed for 
filter measurements (not needed for perfect or pseudo/simple nav inngr); the navigation system 
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structure is needed for model-dependent parameters; the general navigation structure is used to 
housed all necessary navigation parameters for guidance and control; the state and status 
structure is used to pass additional information to the Vehicle Executive for mode transitions; 
and the vehicle executive structure is needed for Phase, Segment, Mode, and Sub-mode 
identification. Figure 1 1 contains an example of the Navigation Manager interface (high rate). 


veh high rate hifi nav 

mngr ( 
$$$$ 

/* 

Others 

as 

needed */ 


Flag 

enable. 

/* 

IN 


-- 

hifi nav enable 

*/ 

pose out T 

* 

LDO, 

/* 

IN 


-- 

LIDAR output 

*/ 

pose out T 

* 

NFO, 

/* 

IN 


-- 

NFIR output 

*/ 

imu out T 

* 

IMUO, 

/* 

IN 


-- 

IMU output 

*/ 

gps out T 

* 

GPSO, 

/* 

IN 


-- 

GPS output 

*/ 

str out T 

* 

STRO, 

/* 

IN 


-- 

Star trckr out 

*/ 

veh hifi nav T 

* 

HFN, 

/* 

INOUT: 

— 

Hi-fi navigation struct 

*/ 

veh veh executive T 

-k 

VEH, 

/* 

INOUT: 

-- 

Vehicle Exec data struct 

*/ 

general nav T 

•k 

NAV, 

/* 

OUT: 

— 

General navigation struct 

*/ 

veh gnc nav ss T 

■k 

SSN) 

/* 

OUT: 

— 

Nav state and status 

*/ 


Figure 11: Navigation Manager Interface Example 


4.5.2 Navigation and UPP Functions (called by Navigation Manager) 

The only interface restrictions on the navigation functions are that the measurement data used 
must come from one of the available sensor output structures and that the necessary parameters 
in the general navigation structure be assigned. The general navigation assignments can be done 
within the navigation functions or in the Navigation Manger. When possible, the general 
navigation parameters should be computed using generic universal parameter processor (UPP) 
type functions. Figure 12 contains examples of some hi-fi navigation function interfaces. 
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veh nav input ( 











$$$$ 

/* 

Others 

as 

needed */ 


double 


time. 

/* 

IN 


s 

Current time */ 


pose out T 

k 

LDO, 

/* 

IN 


-- 

LIDAR output */ 


pose out T 

k 

NFO, 

/* 

IN 


-- 

NFIR output */ 


imu out T 

k 

IMUO, 

/* 

IN 


-- 

IMU output */ 


gps out T 

k 

GPSO, 

/* 

IN 


-- 

GPS output */ 


str out T 

k 

STRO, 

/* 

IN 


-- 

Star trckr out */ 


GKF_Obs 

k 

G) 

/* 

INOUT: 

-- 

Filter observations */ 


veh hifi nav ( 











$$$$ 

/* 

Others 

as 

needed */ 


double 


time. 

/* 

IN 


s 

Current time 

*/ 

GKF Obs 

k 

G, 

/* 

INOUT: 

-- 

Filter observations 

*/ 

general nav T 

k 

NAV) 

/* 

OUT: 

— 

General navigation struct 

*/ 

veh hifi nav T 

k 

HFN) 

/* 

INOUT: 

— 

Hi-fi navigation struct 

*/ 

abs upp ( 









veh hifi nav T 

k 

HFN, 

/* 

IN 


-- 

Hi-fi navigation struct 

*/ 

general nav T 

k 

NAV) 

/* 

OUT: 

— 

General navigation struct 

*/ 

rel upp ( 









veh hifi nav T 

k 

HFN, 

/* 

IN 


-- 

Hi-fi navigation struct 

*/ 

general nav T 

k 

NAV) 

/* 

OUT: 


General navigation struct 

*/ 


Figure 12: Navigation and UPP Function Interface Examples 


4.6 Guidance 

4.6.1 Manager Function (S_define call) 

The minimum data set for the Guidance Manager is an “enable” flag, the general navigation 
structure, the necessary guidance structure(s), the general guidance output structure, guidance 
state and status data structure, and the vehicle executive data structure. The Guidance Manager 
may bring other parameters as needed, but that is all that is required for the architecture. The 
“enable” flag will be set via a local parameter declared in the Sdefine file (set in the input file). 
The general navigation structure is needed for guidance inputs; the guidance structure(s) is 
needed for model-dependent parameters; the general guidance output structure is needed for 
inputs to control; the state and status structure is used to pass additional information to the 
Vehicle Executive for mode transitions; and the vehicle executive structure is needed for Phase, 
Segment, Mode, and Sub-mode identification. Note, the general guidance output structure must 
include, but is not limited to: the commanded force/dv, the commanded and errors in position, 
velocity, attitude, and rate. Figure 13 contains an example of a Guidance Manager interface (high 
rate). 
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cev high rate guid mngr ( 






$$$$ 

/* 

Others as 

needed */ 


Flag enable. 

/* 

IN: 

guidance enable 

*/ 

general nav T * 

NAV, 

/* 

IN: 

(SC->NAV/NAV) (sim config) 

*/ 

veh specific guid T * 

VG, 

/* 

INOUT 

Vehicle guid structures 

*/ 

veh veh executive T * 

VEH, 

/* 

INOUT 

Vehicle Exec data struct 

*/ 

general guid out T * 

GO, 

/* 

OUT: 

General guidance output 

*/ 

veh gnc guid ss T * 

SSG) 

/* 

OUT: 

Guidance state and status 

*/ 


Figure 13: Guidance Manager Interface Example 


4.6.2 Guidance Routines (called by Guidance Manager) 

The only interface restrictions on the guidance functions are that the navigation data used must 
come from the general navigation structure and that the necessary parameters in the general 
guidance output structure be assigned. The general guidance output assignments can be done 
within the guidance functions or in the Guidance. Figure 14 contains examples of a translational 
and rotational guidance function interface respectively. Note, in the translational guidance 
example, the mapping to the general output data structure would be done in the Manager 
function. 


cw bcb maneuvers ( 


double 

time. 


/* 

IN 

s 

Simulation time 


*/ 

double 

mass est. 


/* 

IN 

kg 

Vehicle 

Mass 


*/ 

double 

mean motion. 


/* 

IN 

r/ s 

(NAV->... 

orb rate) 


*/ 

double 

rel pos tlvlh 

[3] 

, /* 

IN 

M 

(NAV->... 

R tcom ccom 

P 
0 
> 
r— 1 

-P 

*/ 

double 

rel vel tlvlh 

[3] 

, /* 

IN 

M/s 

(NAV->... 

V tcom ccom 

tlvlh tlvch) 

*/ 


CW_BURN_C_BURN * BCB) /* INOUT : — Burn coast burn data */ 

cml_att_rate_guid ( 


double 

time. 

/* 

IN: 

s 

Simulation time 

*/ 

I NAV 

* 

N, 

/* 

IN: 

— 

Chaser nav (NAV->...) 

*/ 

I NAV 

* 

TN, 

/* 

IN: 

-- 

Target nav (NAV->...) 

*/ 

RNAV 

* 

RN, 

/* 

IN: 

-- 

Relative nav (NAV->... 

*/ 

ATT RATE 

GUID * 

G, 

/* 

INOUT: 

— 

Att/rate guidance data 

*/ 

general 

guid out_T * 

GO) 

/* 

OUT: 

— 

General guidance output 

*/ 


Figure 14: Guidance Function Interface Examples 


4.7 Control 

4.7.1 Manager Function (S_define call) 

The minimum data set for the Control Manager is an “enable” flag, the general guidance output 
structure, the general navigation structure, the necessary control structure(s), the general control 
structure, the necessary jet selection structure(s), control state and status data structure, and the 
vehicle executive data structure. The Control Manager may bring other parameters as needed, 
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but that is all that is required for the architecture. The “enable” flag will be set via a local 
parameter declared in the Sdefine file (set in the input file). The general guidance output 
structure is needed for control inputs; the general navigation structure is needed for coordinate 
transformations, feed-forward commands, and other miscellaneous computations; the control 
structure(s) is needed for model-dependent parameters; the general control output structure is 
needed for inputs to the effector routines; the jet selection structure(s) is needed for model- 
dependent parameters; the state and status structure is used to pass additional information to the 
Vehicle Executive for mode transitions; and the vehicle executive structure is needed for Phase, 
Segment, Mode, and Sub-mode identification. Note, the general control output structure must 
include, but is not limited to: commanded force and torque, and jet commands. Figure 15 
contains an example of a Control Manager interface (high rate). 


cev high rate control 

mngr ( 

$$$$ /* 

Others as 

needed */ 


Flag 

enable. 

/* 

IN: 

cl enable 

*/ 

general guid out T 

* GO, 

/* 

IN: 

(SC->GO/GO) (sim config) 

*/ 

general nav T 

* NAV, 

/* 

IN: 

(SC->NAV/NAV) (sim config) 

*/ 

CEV CONTROL 

* CON, 

/* 

INOUT 

Veh control struct 

*/ 

CEV JET SELECT 

* JS, 

/* 

INOUT 

Veh jet selection struct 

*/ 

veh veh executive T 

* VEH, 

/* 

INOUT 

Vehicle Exec data struct 

*/ 

general control out 

T * CO, 

/* 

OUT: 

Control guidance output 

*/ 

veh gnc cntrl ss T 

* SSC) 

/* 

OUT: 

Control state and status 

*/ 


Figure 15: Control Manager Interface Example 

4.7.2 Control, Saturation, & Jet Selection Functions (called by Control Manager) 

The only interface restrictions on these functions are that the guidance data used must come from 
the general guidance output structure, the navigation data used must come from the general 
navigation structure, the necessary parameters in the general control structure must be assigned 
(if applicable). The general control output assignments can be done within these functions or in 
the Control Manger. Figure 16 contains examples of translational and rotational control, 
command saturation, and jet selection function interfaces respectively. Note, in the following 
examples, the mapping to the general control output data structure would be done in the Manager 
function. 
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pd pos con ( 









double pos 

err [3] , 



/* 

IN 

-- (GO->pos err) 

*/ 


double vel 

err [3] , 



/* 

IN 

-- (GO->vel err) 

*/ 


double T body cmdfrm[ 

3] 

3] , 

/* 

IN 

— (NAV->... . T cbody tlvlh 

*/ 


double m est. 



/* 

IN 

kg estimated vehicle mass 

*/ 


PD POS CON 

* POS) 



/* 

INOUT: — & (CON->CN2 ) 

*/ 


pd att con ( 









double 

q err[4 

] , 


/* 

IN 

(GO->q err) 

*/ 


double 

rate err [ 3 ] , 

/* 

IN 

(GO->rate err) 

*/ 


double 

T dist [ 3 ] , 


/* 

IN 

disturbance torque 

*/ 


double 

I est [ 3 

] , 


/* 

IN 

kgM2 estimated axial inertia */ 


PD ATT CON 

* ATT) 



/* 

INOUT: — & (C0N->CN1 ) 

*/ 


simplex ( 









double 

dv [ 3 ] , 

/* 

IN: 

M/s 

delta-v trans command (from CO 

param) 

*/ 

double 

dw [ 3 ] , 

/* 

IN: 

r/s 

delta-omega rot command (from 

CO param) 

*/ 

RCS SIMPLEX 

*simplex) 

/* 

INOUT: 

— 

- simplex data structure 


*/ 


Figure 16: Control, Saturation, & Jet Selection Function Interface Examples 


4.8 Effector Functions (S_define calls) 

The only interface restrictions on the effector functions are that the jet selection data (control 
data for perfect effectors) used must come from the general control output structure, and that the 
output force and torque must be in the effector data structure. Figure 17 contains an example of a 
simple effector and an res function interface respectively. 


dvdw FT Imp ( 

double 

* 

c dv. 


/* 

INOUT: 

M/s 

Commanded dv (NULL) 

*/ 

double 

~k 

c dw. 


/* 

INOUT: 

r/s 

Commanded dw (NULL) 

*/ 

double 

* 

c F, 


/* 

INOUT: 

N 

( SC->CO . control force) 

*/ 

double 

* 

dt force. 


/* 

INOUT 

s 

Desired appl time for Force 

*/ 

double 

~k 

c T, 


/* 

INOUT: 

NM 

( SC->CO . control torque) 

*/ 

double 

* 

dt torque. 


/* 

INOUT 

s 

Desired appl time for Torque 

*/ 

double 

* 

c lin imp. 


/* 

INOUT 

Ns 

Cmnd Linear Impulse (NULL) 

*/ 

double 

* 

c ang imp. 


/* 

INOUT 

NMs 

Cmnd Angular Impulse (NULL) 

*/ 

double 


T L I [3] [3] 

r 

/* 

IN: 

-- 

LVLH to INRTL Rot 

*/ 

OrbitalBody 

* 

ORB, 


/* 

IN: 

— 

Veh orbital bdy struc 

*/ 

DynMassGroup 

* 

massgrp. 


/* 

OUT: 

-- 

DynMass struc for veh 

*/ 

DVDW FT IMP 

* 

PF) 


/* 

INOUT: 

— 

Perfect effector struct 

*/ 

res generic ( 

RCS GENERIC 


* R) , 

/* 

Inout: 

(res 

) 

*/ 

DynMassGroup 

* M , 

/* 

Inout: 

The 

dynamic mass group structure 

*/ 

Mass Proper tie 

s * P , 

/* 

In: 

-- 

Composite vehicle mass properties 

*/ 

int *rcs 

command. 

/* 

In: 

"" 

(SC- 

>CO[0].jet cmnds) 

*/ 


Figure 17: Effector Model Interface Examples 
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4.9 Trick Collect Mechanism (Statements in S_define) 


Figure 18 contains an example of a trick collect mechanism interface for force and torque. 


/* COLLECT EFFECTOR FORCES FOR VEHICLE */ 
collect veh . body . orbit . trans . collect effector fore = 
{ 

veh.gnc sim config.eff force [0] 

} ; 

/* COLLECT EFFECTOR TORQUES FOR VEHICLE */ 
collect veh . body . orbit . rot . collect_effector_torq = 

{ 

veh.gnc_sim conf ig . ef f_torque [ 0 ] 

} ; 


Figure 18: Effector & Torque Trick Collection Interface Examples 
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Appendix A: General Vehicle Executive Actions 
♦ Change Phase, Segment, and or Task Immediately (aborts etc.) 

typedef struct { /* cev_veh_executive_T */ 


Flag 

override 

phase; 

/* — 

Yes 

to 

override 

phase (now) 

*/ 

Flag 

override 

segment; 

/* -- 

Yes 

to 

override 

segment (now) 

*/ 

Flag 

override 

task; 

/* — 

Yes 

to 

override 

task (now) 

*/ 


Flag override task completion;/* -- Yes to override task completion (now) * / 


♦ Specify New Phase, Segment, and or Task Upon Nominal Task Completion 

(These commands are used when the nominal task-incrementing is NOT desired.) 

typedef struct { /* cev_veh_task_T */ 

Flag goto phase; /* -- Yes to jump to specified flight phase upon 

task completion */ 

Flag goto segment; /* -- Yes to jump to specified flight segment 

upon task completion */ 

Flag goto_task; /* -- Yes to jump to specified task upon 

task completion */ 

♦ Repeat a Set of Tasks or Skip the Next Task 

typedef struct { /* cev_veh_task_T */ 

Flag repeat_tasks ; /* -- Yes/No to repeat a set of tasks */ 

Flag skip next task; /* -- Yes/No to skip the next task */ 


♦ Optional “Go” (authority to proceed) for Mode Transition 

typedef struct { /* cev_veh_task_T */ 

Flag go needed; /* -- Yes/No on needing a "go" for next task */ 

Flag go; /* -- Yes/No for task execution (if needed) */ 


♦ Update Task Data 

typedef struct { /* 

Flag update_t_guid_data; /* - 

Flag update_a_guid_data; /* - 

Flag update_t_nav_data; /* - 

Flag update_a_nav_data; /* - 

Flag update_t_cntrl_data; /* - 

Flag update a cntrl data; /* - 


cev_veh_task_T */ 

Yes/No to update trans guid task data */ 
Yes/No to update att guid task data */ 
Yes/No to update trans nav task data */ 
Yes/No to update att nav task data */ 
Yes/No to update trans cntrl task data*/ 
Yes/No to update att cntrl task data */ 


